Feat/respect keyboard layout in code fallback#53
Merged
KevinVandy merged 4 commits intoTanStack:mainfrom Mar 7, 2026
Merged
Conversation
…youts The `matchesKeyboardEvent` function falls back to `event.code` (physical key position) when `event.key` doesn't match the hotkey. This fallback exists to handle cases like macOS Option+T producing '†' instead of 'T'. However, when `event.key` is already a standard ASCII letter, this fallback incorrectly matches based on physical key position, breaking all non-QWERTY keyboard layouts (Dvorak, Colemak, AZERTY, etc.). For example, on Dvorak with macOS "Use keyboard layout for shortcuts": - Pressing Cmd + physical B key produces event.key='x', event.code='KeyB' - A hotkey registered as 'Mod+B' would incorrectly match via the code fallback, even though the user pressed Cmd+X in their layout The fix: when event.key is a standard ASCII letter (a-z), trust the keyboard layout mapping and skip the event.code fallback. The fallback is still used when event.key is a non-letter character (like '†') or a dead key. Fixes TanStack#17
@tanstack/hotkeys
@tanstack/hotkeys-devtools
@tanstack/preact-hotkeys
@tanstack/preact-hotkeys-devtools
@tanstack/react-hotkeys
@tanstack/react-hotkeys-devtools
@tanstack/solid-hotkeys
@tanstack/solid-hotkeys-devtools
commit: |
KevinVandy
force-pushed
the
feat/respect-keyboard-layout-in-code-fallback
branch
from
df20bf1 to
467f93c
Compare
Member
|
@dmontagu I think I was able to solve non-ascii too by using regex |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🎯 Changes
Fixes #17
The
matchesKeyboardEventfunction falls back toevent.code(physical key position) whenevent.keydoesn't match the registered hotkey. This fallback exists to handle cases where modifier keys cause the OS to report a special character instead of the expected letter (e.g., macOS Option+T producing†instead ofT).However, the fallback currently activates even when
event.keyis a standard ASCII letter — which means it matches based on physical key position rather than the keyboard layout's logical mapping. This breaks all non-QWERTY keyboard layouts (Dvorak, Colemak, AZERTY, etc.):Example on Dvorak (macOS with "Use keyboard layout for shortcuts" enabled):
event.key='x',event.code='KeyB'Mod+Bchecks:'x' === 'b'? No.event.code = 'KeyB'→'B' === 'B'? Yes → hotkey fires incorrectlyThe fix: When
event.keyis already a standard ASCII letter (a-z), trust the keyboard layout and returnfalseimmediately. Theevent.codefallback is still used whenevent.keyproduces a non-letter character (e.g.,†,´, dead keys).(To be clear, this "example" was a real issue in our Pydantic Logfire app, and is precisely how I noticed this bug, as I am a Dvorak user myself. I have applied the diff from this PR in our own frontend build via pnpm patches, and the problem is now fixed for me.)
✅ Checklist
pnpm run test:pr.🚀 Release Impact